1. Field of the Invention
The present invention relates to a method used in a service system, and more particularly, to a method of providing radio access technology information of a device in the service system.
2. Description of the Prior Art
The Open Mobile Alliance (OMA) is founded to develop OMA specifications for mobile services to meet users' needs. Furthermore, the OMA specifications aim to provide the mobile services which are interoperable across geographic areas (e.g. countries), operators, service providers, networks, operation systems and mobile devices. In detail, the mobile services conforming to the OMA specifications can be used by the users without restriction to particular operators and service providers. The mobile services conforming to the OMA specifications are also bearer agnostic, i.e., the bearer that carries the mobile services can be a second generation (2G) mobile system such as GSM, EDGE or GPRS, or a third generation (3G) and beyond mobile system such as UMTS, LTE or LTE-Advanced. Further, the mobile services can be executed on an operation system such as Windows, Android or Linux operated on various mobile devices. Therefore, industries providing devices or the mobile services supporting the OMA specifications can benefit from a largely growing market enabled by interoperability of the mobile services. Besides, the users use the devices or the mobile services supporting the OMA specifications can also have a better experience due to the interoperability of the mobile services.
In OMA Device Management (DM) requirement, a Management Authority (MA) is defined as an authorized legal entity which can manage one or more DM clients (e.g. mobile devices) by using a DM protocol conforming to the OMA specifications. Furthermore, according to deployment of a system supporting the OMA, the MA may directly manage the DM client, or the MA may manage the DM client via one or multiple DM servers, i.e., the DM client is actually managed by the one or the multiple DM servers. In detail, the DM protocol defines a way according to which a packet or a message is exchanged between the DM server and the DM client. The DM protocol also defines a way according to which the DM client can feedback a command, a status or a report to the DM server. Further, when using the DM protocol, the DM server manages the DM client through a set of management objects in the DM client. Management objects are logical collections of related nodes that enable the targeting of management operations. Each node in a management object may be small as an integer or large and complex like a background picture or screen saver.
Management objects defined in the DM specification include DevInfo management object and DevDetail management object. In DevInfo management object, device information for the DM server is recorded. In DevDetail management object, general device information that benefits from standardization is recorded. The difference between DevInfo and DevDetail is that the DevInfo parameters are needed by the management server for problem free operation of the OMA DM protocol. The DevInfo object is sent from client to server in the beginning of every session. Besides, Diagnostics and Monitoring (DiagMon) management object is defined to manage distributed, mobile wireless devices, in order to optimize a subscriber's experience and reduce network operating costs. There are functions defined in DiagMon related to RF metrics (i.e. 2G/3G measurement). DM server invokes these functions to ask DM client to measure and record the current RF information (e.g. Radio Access Technology (RAT) used by the DM client).
However, in OMA DM specification, there is no clear method defined for providing a current RAT of DM client, which conceptually sits between the mobile device and the core network (CN) of a wireless communication system to complete the wireless telecommunication, such as GSM, WCDMA, LTE, and non 3GPP radio access technologies. Therefore, the DM server may starting the wrong RF metrics function defined in DiagMon or retrieve wrong or out-of-date data of RF metrics since a RAT currently used by the DM client for communicating with the core network of the wireless communication system is not provided. More specifically, since the DM server does not know the current RAT of the DM client, the DM server may configure improper measurement configuration to the DM client, and thereby receiving wrong or out-of-date data of RF metrics.
Please refer to FIG. 1, which is a schematic diagram of a DevDetail management object tree. Note that, even though a node “CBT” (current bearer type) is defined in DevDetail management object tree in FIG. 1, it is still insufficient and ambiguous to know which RAT is used for communicating with the core network since “CBT” only provides bearer type information over which the DM session is currently being carried. For example, a DM client camped on UMTS network may use Wi-Fi to establish DM session with a DM server at very beginning, and the node “CBT” records a value indicating Wi-Fi. However, when the DM server uses the RF metric function, the DM server probably starts the wrong RF metrics function or retrieves wrong or out-of-date data of RF metrics, since the RAT currently used for communicating with the core network (which is UMTS in this example) is not provided.
Moreover, with only one value “3GPP packet Switched Bearer” corresponding to 3GPP packet Bearer defined in CBT, DM server cannot distinguish UMTS and GSM access technology. In a word, the DM server has no idea which RAT of DM client is applied, and thereby the DM server starting the RF metrics function defined in DiagMon may retrieve wrong or out-of-date data of RF metrics.